Access Control List
(QW.LocationAcl)
Overview
This is a private feature developed by Qwilt.
Use access control lists (ACLs) to limit access to your site based on a client's IP address, geographic location, autonomous system number (ASN), or use of anonymizer. ACLs can be defined at the site, host, and path levels.
- Site-level ACLs are inherited by hosts
- Host-level ACLs are inherited by paths
- An ACL defined at a lower level (host or path) overrides any inherited ACL settings from a higher level.
Default Access Behavior
When defining an ACL, first consider the Default Access setting.
- Deny All (default) - All requests are denied unless explicitly allowed by a rule.
- Allow All - All requests are allowed unless explicitly denied by a rule.
Then, define ACL rules to specify exceptions to the default behavior. You may define multiple ACLs at any level (site, host, path). Each ACL can contain one or more rules.
Rule order matters. The CDN evaluates the ACL rules sequentially, and applies the first matching rule to each request.
Examples
Example 1: Default Access is Deny All
This example allows access to non-anonymous users from the US or the UK.
{
"generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.LocationAcl",
"generic-metadata-value": {
"rules": [
{
"action": "deny",
"locations": [
{
"match-type": "named-list",
"match-values": [
{
"name": "anonymous-users",
"match-method": "match"
}
]
}
]
},
{
"action": "allow",
"locations": [
{
"match-type": "countrycode",
"match-values": [
"us",
"uk"
]
}
]
}
]
}
}
How it works:
- The first rule denies access to anonymous users.
- The second rule allows access to non-anonymous users from the US or UK.
- All other requests are denied by default, because they do not match any rule and the implicit behavior is Deny All.
Example 2: Default Access is Allow
This example denies access to anonymous users, but allows all other requests. An explicit "allow all" rule is added to the end of the array.
{
"generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.LocationAcl",
"generic-metadata-value": {
"rules": [
{
"action": "deny",
"locations": [
{
"match-type": "named-list",
"match-values": [
{
"name": "anonymous-users",
"match-method": "match"
}
]
}
]
},
{
"action": "allow",
"locations": [
{
"match-type": "named-list",
"match-values": [
{
"name": "any",
"match-method": "match"
}
]
}
],
"comment": "Default access: allow"
}
]
}
}
How it works:
- Anonymous users are denied first.
- The final rule explicitly allows all other requests.
- The last rule acts as a catch-all for any request that didn't match earlier rules.
SVTA Object Format
Each ACL rule is expressed in the generic-metadata-value
field, which contains an array of rule objects.
Rule Structure
Each rule includes the following fields:
- action: Either
"allow"
or"deny"
- locations: An array of match conditions.
- comment (optional): A string that describes the purpose or context of the rule.
Match Conditions
Each item in the locations
array is an object that specifies a match condition. It includes the following fields:
- match-type: The type of condition to evaluate. Valid values are
ipv4cidr
,ipv6cidr
,countrycode
,asn
, andnamed-list
. - match-values: An array of values to match against. The expected format depends on the
match-type
.
Supported Match Types
match-type | Corresponding match-values Format | Examples |
---|---|---|
ipv4cidr | Array of IPv4 CIDR blocks. | ["192.0.2.0/24", "198.51.100.10/32"] |
ipv6cidr | Array of IPv6 CIDR blocks. | ["2001:db8::/32"] |
countrycode | Array of ISO 3166-1 alpha-2 country codes. | ["us", "gb", "ca"] |
asn | Array of Autonomous System Numbers (without "AS" prefix). | ["7018", "15169"] |
named-list | Array of objects with name and match-method fields. | See structure below. |
Named List Format
When the match-type is named-list
, the match-values field contains the following:
Field | Description | Valid Values |
---|---|---|
name | The name of the predefined match list. | - anonymous-users - local-asn - any |
match-method | How the list should be evaluated | - match - no-match |
Rule Evaluation Behavior
The order of rules within the rules
array matters. The CDN evaluates rules sequentially, and the first matching rule determines the outcome (allow or deny).
- Rules are evaluated in order.
- The first rule that matches a request is applied.
- No further rules are evaluated once a match is found.